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BACKGROUND OF THE INVENTION 

Field of the Invention 

The present invention relates to the field of on-line catalogs, and more particularly to 
generating customized versions of an on-line catalog for each of an arbitrary number of 
different buyers, the customized versions being the results of rules-based searches of a central 
catalog database maintained by the seller. 

Description of the Related Art 

With the advent of Internet based commerce, organizations on both the buy and sell 
side of business-to-business (B2B) procurement relationships have sought to harness 
computer networks as a means for automating the procurement process between them. To 
facilitate e-commerce, and particularly e-procurement, suppliers of goods and services have 
developed electronic catalogs by which potential buyers can electronically receive and 
display information regarding the goods and services offered by the supplier, including 
descriptive information, pictures and prices. 

For many reasons, a seller does not often find it desirable to supply the same catalog 
to all buyers. It may be preferable for a catalog targeted to businesses to have a different 
product focus than a catalog for individual consumers, and the scope of products in a catalog 
may vary from one type of business to another, as well as from one type of consumer to 
another. For example, the types of computers and peripherals offered to businesses may 
provide higher performance and as a result are more costly than computer equipment targeted 
toward consumers. The types of goods and services marketed to one type of business often 
vary significantly from those targeted toward another type of business. Moreover, buyers 
that purchase high volumes of products/services will often negotiate unique pricing 
agreements with sellers that afford significant discounts compared to lower volume 
purchasers. Thus, it would be highly desirable from the seller's perspective for each buyer or 
group of buyers to have their own unique catalog, one that is customized to reflect the 
individual product interests of each customer or customer group, as well their unique business 
processes and relationships. 

For a seller carrying many different items (or providing many classes and types of 
services), maintaining even one version of an e-catalog can be extremely difficult. To 
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maintain several custom versions of an electronic catalog, a physical manifestation of each 
custom version is typically created and each version must be maintained and updated as the 
catalog data changes. Each time a product or service is added, or its attributes or attribute 
values are changed, every physical manifestation of a version of the catalog must be 
5 individually updated to ensure that each version reflects the changes in the catalog data. Each 
version essentially is obsolete until updated. 



that an update must be performed for each existing version of the catalog can be time- 
consuming, labor intensive and prone to error. Moreover, updating multiple versions of the 
slO catalog is made even more onerous because they typically reside at different physical 
^ locations, to many of which the seller has no direct access. For example, some versions of 
01 the catalog may have been published to buyers' proprietary retail web sites, some to public 
j|i marketplace web sites and still other versions to procurement networks. These common 
H = repositories for at least a subset of a seller's catalog information typically are not directly 
==15 accessible to the seller for making direct updates to the catalog information. Rather, catalog 

updates for these buyers typically must occur somewhat indirectly and through the 
^ cooperation of the buyer. In these contexts, the buyer usually performs the ultimate 
O integration of the custom versions of the catalog into the buyer's web site or procurement 
5 ~" network. 

20 Thus, for the seller to provide customized versions of its catalogs to all of its potential 

customers, prior art techniques have required the seller to assume a tremendous 
administrative burden to maintain the various versions of its catalog, leading to discrepancies 
and errors. For example, some versions may continue to include products or services no 
longer offered by the seller. Another error that can occur is that some of the prices in a 

25 version of the catalog have become obsolete. Buyers attempting to purchase products or 
services still in the catalog but no longer available through the seller will not be happy that 
they were inconvenienced in such a manner. Obsolete prices can mean lost money to a seller 
if new higher prices are not reflected by a custom version of the seller's catalog. Thus, trying 
to maintain and update so many versions of a catalog becomes risky as well as labor- 

30 intensive, which tends to offset many of the advantages of providing electronic catalogs. 



Although each version of an electronic catalog is maintained by computer, the fact 
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It would be highly desirable from the seller's perspective if the seller could maintain 
all catalog data in a central database and in one physical location, and then generate 
customized versions of its catalogs for its various buyers and buyer groups based on the 
central database. It would also be preferable if buyers were coupled to the catalog database 
through a network, so that the seller could present the customized versions of its catalog data 
to its buyers on a virtual basis, rather than publishing and delivering physical manifestations 
of the customized versions. 

SUMMARY OF THE INVENTION 

In one embodiment, the method of generating a plurality of custom catalogs from a 
central database comprising catalog data generally comprises establishing a plurality of rule 
sets, each of the rule sets expressing constraints that define a subset of the catalog data 
comprising one of the custom catalogs, each of the rule sets identified by one of a unique set 
of rule set identifiers, of executing a search of the central database for each of the rule sets in 
accordance with the constraints expressed by each rule set, each of the searches returning a 
set of search results specifying a subset of the catalog data, and of associating each set of 
rules set search results with the identifier of the rule set used to generate them. In this way, a 
set of search results is generated for each rule set that can be used to create virtual custom 
catalogs or physical manifestations thereof. 

In one embodiment, the method of generating custom catalogs responds to a database 
query of an extranet buyer specifying a search of the database of arbitrary scope and 
associated with one of the rule set identifiers generally by executing a search of the database 
in accordance with the query, the search returning a set of query results and generating a 
response to the query that is a subset of the catalog data specified by the intersection between 
the set of query results and the set of search results associated with the rule set identifier 
specified by the query. In this way, the extranet buyer has access to a virtual custom catalog 
that is customized on a query by query basis. 

In another embodiment, the method of generating custom catalogs retrieves the 
catalog data specified by each of the sets of rule set search results, creates a distinct database 
file consisting of the retrieved catalog data for each, and exports each distinct database file to 
an entity associated with the identifier of the rule set used to generate the rules set search 
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results. This is one embodiment by which custom catalogs can be generated from the central 
database and exported to non-extranet buyers. 



includes a database storage device in which the catalog data is stored, and a database server 
by which the catalog data is searched and accessed in accordance with the invention. An 
application server communicates with the database server to initiate the searches, maintain 
the rules sets and to interact with users through the web server. The web server provides 
access to the database to users by means of a browser over the Internet. 

In another embodiment, the application server executes a series of computer program 
instructions, which by their execution, performs the method of generating custom catalogs. 

BRIEF DESCRIPTION OF THE DRAWINGS 

The present invention may be better understood, and its numerous objectives, features 
and advantages made apparent to those skilled in the art by referencing the accompanying 
drawings. The use of the same reference number throughout the several figures designates a 
like or similar element. 

Figure 1 shows a bock-diagram representation of a general embodiment of the method 
and apparatus for generating custom catalogs. 

Figure 2 shows a block diagram representation of one extranet embodiment of the 
method and apparatus for generating custom catalogs. 

Figure 3a shows an example of how the catalog database is arranged for maintenance. 

Figure 3b shows an example of how a read-only copy of the centralized catalog 
database of Fig. 3a is arranged during publication of custom versions to facilitate the searches 
by which the versions can be generated. 

Figure 4 illustrates a subset table generated by the method and apparatus for 
generating custom catalogs. 

Figures 5a-c illustrate the procedural flow of one embodiment of the method of 
generating custom catalogs. 



An embodiment of an apparatus for generating custom catalogs is disclosed that 
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Figures 6a-h are browser screen shots, displayed to a seller-authorized user, 
illustrating one embodiment of a browser interface by which rule sets defining custom 
catalogs may be created. 

DETAILED DESCRIPTION 
Overview 

One embodiment of the method and apparatus of the invention generates an arbitrary 
number of customized versions of a seller's catalog for an arbitrary number of buyers or 
buyer groups from a centrally maintained catalog database consisting of all of the seller's 
catalog data. The seller's catalog database is centrally managed and maintained. The seller's 
catalog database consists of data representing some or all of the products or services (i.e. 
items) offered by the seller. Each item is categorized using a product type having a set of 
attributes and a unique set of values for those attributes. Each item is identified with a unique 
SKU, and is represented in the database by its SKU and each of its attribute values. Also 
associated with each item SKU is descriptive information (e.g. descriptive text, pictures, and 
the like) normally associated with the display of such items in a catalog. 

A buyer's custom version of the seller's catalog consists of a subset of the items in the 
catalog database, the scope of which has been predefined for each buyer. The scope of each 
subset of items, and therefore the scope of each custom version of the catalog, is precisely 
defined by a set of rules that is developed and assigned to each buyer. Each set of rules is 
associated with a unique identifier, and each buyer is assigned to one set of rules through its 
associated identifier. Those of skill in the art will recognize that some buyers will have 
common product or service interests and therefore will share the same customized catalog, 
and thus will be assigned to the same set of rules by a common identifier. Each set of rules 
constrains a search of the database based on a product type and a set of attribute values, and 
when the search is executed returns a set of SKUs from the catalog database. Each SKU 
number identifies a unique item consisting of a unique set of attribute values. 

In one embodiment of the method and apparatus for generating custom catalogs, the 
seller performs a virtual publication process on a regularly scheduled basis to update all of 
the custom versions of the catalogs to reflect any changes made to the catalog database since 
the last update. During the publication process, the catalog database is temporarily locked so 
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that no further modifications can be made to the catalog database until the virtual publication 
process is complete. A search of the catalog database is then executed as constrained by each 
set of rules to generate a new set of SKUs for each rule set. Each of the resulting sets of 
SKUs is associated with the identifier of the rule set used to generate it. The sets of SKUs 
resulting from this virtual publication process are then used to generate custom catalogs in 
different modes depending upon the type of buyer for which the custom catalog is to be 
generated. 

In another embodiment, the buyers are coupled to the seller's catalog database 
through an extranet, which is a network connection established between buyer and seller over 
the Internet. In this embodiment, buyer's make catalog inquiries through a web browser. 
The inquiries are received by seller's web server application and handled by the seller's 
application program. In this way, the seller can directly control what data from the catalog 
database each buyer sees. The responses from the seller to each buyer's inquiries can 
therefore be limited to that set of SKUs generated using the buyer's assigned set of rules. 
Thus, versions of the catalog data customized for a particular buyer are essentially logical 
constructs; the scope of catalog data retrieved from the catalog database in response to a 
seller's inquiry can be can be constrained based on the rules specific to that buyer before 
being presented (i.e. displayed). 

In another embodiment, custom versions of the catalog database are exported to 
external buyers not coupled to the seller's catalog database through an extranet connection. 
The scope of the catalog data comprising these exported custom versions are also constrained 
to the set of SKUs constrained by the set of rules assigned to the buyer, and generated during 
the virtual publication process. The difference is, the set of SKUs is used to create a 
complete physical manifestation of the custom version of the seller's catalog for the buyer 
(rather than doing so on a query by query basis as in the extranet embodiment). This physical 
manifestation of the buyer's custom version of the catalog data (consisting of all descriptive 
and attribute information for each SKU in the set) is then physically exported in its entirety to 
the buyer's site for incorporation. 

In another embodiment, the method of generating custom catalogs is performed by 
program instructions of an application software program. In one embodiment, an application 
server executes the application program to perform the method of the invention. 
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The set of rules defining each custom version of the catalog is maintained 
independently from the catalog database. Thus, when the catalog database is modified, all 
custom catalogs can be updated concurrently by simply performing the virtual publishing 
process on the new version of the catalog database. This process involves re-running all of 
5 the searches to generate a new set of SKUs for each rule set to propagate any changes in the 
database that should be reflected in the custom versions of the catalog. Maintaining the rule 
sets used to generate a custom catalog for each buyer independently from the database also 
permits the rule sets to be modified for existing buyers and/or created for new buyers without 
affecting the catalog database. Modifications for the rule sets will also be reflected in the 
10 updated custom versions of the seller's catalog after virtual publication is complete. The rule 
O sets that define the constraint-based searches to generate each custom catalog are then 
m executed and the results of each search are returned in the form of a set of item SKUs the 

scope of which is constrained by the rules. Each buyer or buyer group is assigned to one of 
P.J the rule sets. 

15 Structure and Methodology 

Referring to Fig. 1, a block-diagram representation of the apparatus for generating 
yj custom catalogs is depicted. Catalog database 10 contains the most recent version of the 

catalog data assembled and maintained by the seller. The catalog data stored in the database 
10 is accessed through queries made to database server 9. Database server 9 can be any 
20 server capable computer, including one capable of running SQL Server 7 by Microsoft. 
Product or service information can be imported into database 10 via import input 24 from 
manufacturers and vendors of products sold by the seller. A format such as XML (extensible 
Mark-up Language) can be used to represent the imported data for easy manipulation and 
conversion. 

25 Users authorized by the seller may be given access to the database 10 through an 

application program running on application server 8, which is in communication with the 
database server 9 through communications bus 32. The application server 8 can be any 
server capable computer, including a PC server capable of running the Windows NT ® 
operating system available from Microsoft Corporation. Updates to and maintenance of 

30 database 10 can be made directly by the seller-authorized users through the application 

program. In one embodiment of the invention, the application server 8 communicates with 
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database server 9 over bus 32 using TCP/IP communications protocol and JDBC/ADO 
database protocols. 

The set of arbitrary rules used to define the scope of the subset of catalog data to be 
included in each custom catalog is created by seller-authorized users through terminals 38 
5 coupled to application server 8. The rules are physically stored with (although maintained 
independently from) the catalog data in database 10. The search queries derived from these 
rules are used by the database server 9 to search and retrieve the subsets of the catalog data 
for each custom catalog during the publishing process. The application formulates the series 
of queries based on the rules and issues those queries to the database server 9. The database 
10 server 9 searches and retrieves a subset of the catalog information in the form of item SKUs 
Iff in response to the queries and of a scope that is constrained by the rules. 

lz Each set of rules is associated with a unique identifier, and each buyer for which a 

! V custom catalog is to be generated is assigned an identifier corresponding to the set of search 

rules that defines the scope of the content of the custom catalog for that buyer. Typically, 

ftp the seller-authorized users who are charged with maintaining the database and setting up 

I' : = buyer accounts perform this function through terminal(s) 38. A more detailed discussion of 

3 J the rules and the method of publishing the custom catalogs to various types of buyers are 

ilL presented below. 

Fig. 1 illustrates that customized versions of the seller's catalog data can be provided 
20 to buyers using the present invention in different modes, depending upon the type of buyer. 
One mode of providing customized versions of seller's catalog is employed for an extranet 
relationship between the seller and certain buyers. An extranet is simply a business-to- 
business link between the seller and one or more buyers using the Internet 40. In this case, 
web server 12 couples buyer-authorized and seller- authorized users to the application server 8 
25 over the Internet 40. Thus, buyer-authorized users can access and browse the seller's catalog 
data directly using a computer such as a personal computer (PC) 36 running a web browser. 
An extranet buyer initiates catalog queries through the browser, which are received over 
Internet 40 by the seller's web server application. The seller services the query by way of the 
application running on the application server 8. The buyer's access is direct and the seller 
30 has direct control over the responses produced by the buyers' inquiries. Thus, the seller can 
limit the scope of any response to buyer's query simply as a function of the set of SKUs 
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returned for that buyer during the virtual publication process. In this mode, the seller 
provides a virtual custom catalog for each buyer instead of having to publish a physical 
manifestation of some subset of the catalog data that comprises each custom version. 

For the extranet, seller-authorized users can perform database maintenance either over 
5 the Internet 40 using a machine such as a PC running a web browser 38, or directly with the 
application server 8 as previously discussed. Both the seller and the buyer(s) authorize users 
to access the application running on application server 8, which is accomplished through web 
server 12 coupled to browsers 14 over the Internet 40. Those of skill in the art will recognize 
that a single server could be used to run both the application as well as the web server 
1=Q application. Because the buyer has direct access to the database 10 through extranet web 
jii server 12 and application server 8, updates to the virtual custom catalogs for the extranet 
m buyers are available immediately upon completion of the publication process. 

\ll A second mode in which customized catalogs can be provided to is through the 

y - process of exportation. One context for which exportation of customized catalogs is 

ft? appropriate is when a buyer offers its own catalog of products or services through its own 

j;\ proprietary commercial web site 11. In this case, the buyer may wish to incorporate a subset 

yl of the seller's catalog data describing products or services of the seller that the buyer wishes 

iai to sell through its web site 1 1 . Potential purchasers of the buyer's products or services 

typically access the buyer's proprietary web site 1 1 through browsers 13 over Internet 40. 

20 A second possible context for which exportation is applicable is a public marketplace, 

whereby two or more buyers establish a proprietary web site, through which they offer 
products or services including some of the seller's products or services. As in the previous 
example, proprietors of the public marketplace may wish to incorporate some subset of 
seller's products or services with some pricing scheme into its catalog. Customers of the 

25 public marketplace web site access the custom catalog information through browsers 18 over 
the Internet 40. 

Another context in which exportation of customized catalog and pricing is applicable 
is when a seller wishes to offer some customized subset of its catalog to the many potential 
purchasers that belong to a private procurement network 20. Member buyers and sellers are 
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authorized to access the procurement network, either directly using terminals 17, or indirectly 
through Internet 40 using browser 15. 

In all of the foregoing contexts, exportation is used because the seller typically does 
not have direct access to the buyer's web site. Moreover, the catalog data comprising the 
5 customized subset of the catalog database often must be converted to some format of the 
buyer's specification prior to exportation. This could be a fairly standard format such as a 
version of XML, or it might be a more proprietary format in the case of a procurement 
network. For the foregoing contexts, because the seller typically does not have direct access 
to the catalog data maintained by the buyers for the foregoing contexts, the newly generated 
JLQ custom catalog information generated by the seller must be exported to and incorporated by 
41 the buyer. Nevertheless, the method and apparatus for generating custom catalogs can be 
131 used to create and update the exportable manifestations of custom catalogs using the same 
:|; virtual publication process as applied to the extranet environment. The primary difference is 
h- how the sets of SKUs produced by the publication process are used to generate the custom 
$ 5 catalogs. For extranet buyers, the sets of SKUs are used to constrain the results of catalog 
:^ inquiries to provide a virtual custom version of the catalog for each extranet buyer. For non- 
H extranet buyers, the sets of SKUs are used to create a complete physical manifestation of the 
f \ custom catalog for exportation to the buyer. 

In both the extranet context and the non-extranet context, the fact that the customized 
20 catalog for a particular buyer is a subset of the items contained in the full catalog database 10 
is completely transparent to the buyers. The seller maintains the central database 24, and 
customized versions are virtually published to the various extranet buyers, and physical 
manifestations of the customized versions are exported to external buyers, based on the 
content rules unique to that customer. 

25 Fig. 2 illustrates one extranet embodiment of the invention. A database server 9 

provides access to central catalog database 10. The database server 30 receives queries from 
application/ web server 34 over bus 32 using an appropriate communication and database 
protocol such as TCP/IP and JDBC/ADO respectively. As previously discussed, the 
application of the present invention and the web server application can be run on the same 

30 machine. Seller-authorized users can maintain and update the catalog database 10, and create 
new extranet accounts with buyers using terminals 38. The seller-authorized users can access 
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the application directly or over the Internet 40 through the web server application. New 
catalog data can be imported into database 10 from manufacturers, suppliers, etc. over XML 
import input 33. An example of an import file formatted in XML is attached hereto as 
Appendix A. The application/web server 34 typically runs an operating system such as 
5 Windows NT 4/IIS, available from Microsoft Corporation, or some version of Unix. A more 
detailed discussion of the format of the catalog data, the rules and the searches performed to 
create the custom catalogs follows. 

Those of skill in the art will recognize that database 10 can be coupled to server 34 
and to additional servers, if one desires to expand the number of extranet connections to an 
10 arbitrary number of buyers. Moreover, the rules-based re-publishing of custom catalogs can 
l = {% be used to customize versions of the catalog for any number of proprietary web sites, public 
]ff marketplaces and procurement networks. 

flj With reference to Figs. 5a-5c, a detailed description of one embodiment of the method 

\y% of generating custom catalogs is now presented. As illustrated by step 50 in Fig. 5a, the 
15 catalog database 10 is established, updated and modified through importation of 
01 vendor/supplier data and/or through direct input by seller-authorized users as previously 
k ; discussed. In one embodiment, catalog data is stored in a database storage medium and can 
H be categorized as catalog data and metadata. Catalog metadata includes product types and 
attributes. In one embodiment, each item is represented by a unique SKU ID (identifier) in 
20 the catalog database, and belongs to exactly one product type. Unless an attribute is one that 
is deliberately made common to more than one product type, each attribute belongs to exactly 
one product type and is identified by a unique attribute ED. Each product type is also 
uniquely identified with a product type ID. Those of skill in the art will recognize that the 
most common way to uniquely identify something in a table is with some form of 
25 alphanumeric identifier. Some examples of product type might be personal computer, 

memory, and hard-drive. Some examples of attributes that might be uniquely associated with 
such product types might be processor clock speed, memory size, vendor and capacity 
respectively. Catalog data typically consists of part specific data such as attribute value pairs. 
Examples are color = blue, size = 64k, processor speed = 800 MHz, etc. 

30 Figure 3a illustrates a simple example of how the data is arranged in the database to 

facilitate maintenance, and Fig. 3b illustrates how the data of Fig. 3 a is transformed at the 
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time of publication to facilitate the rules-based searching by which the catalog subsets are 
generated. In Fig. 3a, the data is arranged such that there is only one attribute/value per row. 
Thus, each item SKU as well as each product type can have multiple rows. For example, the 
item associated with SKU #123 has a row for each of its associated attributes. Attribute #1 
5 (ATT#1) = vendor, ATT#2 = processor clock speed, ATT#3 = memory size, ATT#4 = 

modem speed. Item SKU #123 is of product type 1 = desktop computer. The item uniquely 
identified by SKU #321 has a row for each of its 4 attributes. ATT#5 = vendor, ATT#6 = 
print type, ATT#7 = print speed, ATT#8 = print resolution. Item SKU 321 is of product type 
= 2 = printer. It should be pointed out that not all attributes must require a value, but for 

10 those that do, the application of the present invention will force a user to insert a value. 

O Additionally, certain attributes (ATT-IDs) can be linked as common, so that searches can be 

m performed that return, for example, all item SKUs having a value for that common attribute, 

5 *I regardless of product type. 

H Processing continues at processing step 50 where sets of rules are established for each 

15 buyer in accordance with the scope of the custom catalog that is appropriate to the particular 
buyer. Buyers for whom the appropriate scope is the same will be assigned to the same rule 
h= set. Each rule set is given an identifier, and each buyer is associated with a particular rule set 
PI through the identifier. In one embodiment of the present invention, rules are specified in the 
I=s form of either an include (INC) or exclude (EXC), and are constrained based on product type 
20 and att/val pairs. Each rule is implicitly ANDed together with all other rules for a particular 
buyer. They are performed sequentially and take the general form: 
INC/EXC 

All parts where: 

[ATT_Name op ATTVal 
25 (AND) [ATT_Name opATT_Val] 

. ] 

where ATT Name equals an attribute identifier, op is an operator {=, >, <, "starts 
with" or "contains"}, ATTVal is the value of the attribute to be included or excluded, and 
the AND is implicit. 

30 Thus, an example search to include all software that is manufactured by Microsoft 

Corporation and is related to "Windows" could be expressed as follows: 
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INC 



All parts where: 

[Product type = 'software' 

[Vendor = 'Microsoft' 



[Description "starts with" 'Windows'] 



This search would return the SKUs for products such as Windows NT®, Windows 
95®, Windows 2000® operating systems or applications developed by Microsoft that are 
described as Windows® compatible. One could add to the search to further narrow the 
results by excluding all parts described as being Windows 95® compatible. Thus, one can 
further exclude items that have been included, or include some parts that were previously 
excluded. For example, one could append to the previous example to include all parts that 
have a vendor = 'Oracle.' A set of rules is created using this format for each buyer for whom 
the seller wishes to provide a customized catalog. 

The format illustrated in Fig. 3 a is designed to facilitate the creation and maintenance 
of the catalog data. However, it is not optimal for searching for items having certain attribute 
values. Thus, as illustrated by step 52 of Fig. 5a, upon commencement of publication (i.e. 
when new and/or updated custom catalogs are to be generated), the catalog database is locked 
and the data is converted to the format illustrated in Fig. 3b. A table is created for each 
product type, and each table comprises just one row per SKU, and a column for each attribute 
belonging to the product type. The tables of Fig. 3b include some additional item SKUs not 
shown in Fig. 3 a to illustrate that other items can fall under the product type, and that each 
item SKU has a unique combination of the att/val pairs. The advantage to the converted 
format is that when a searches are performed on the data, the amount of data to be searched 
can is pared down first based on product type, and then by attribute/value (att/val) pairs. 

It should be noted that the conversion process produces a read-only copy of the 
original database in the search-friendly format. Thus, the conversion process does not disturb 
the data in the database as configured in the maintenance-friendly format. In fact, once the 
format conversion process is completed, the original database is unlocked so those seller- 



-14- 



711395 v4 




'Attorney Docket No.: M- 10957 US 
Client Reference No. T00041 



authorized users can continue updating the catalog database without disturbing the publishing 
and exporting processes. 

Those of skill in the art will recognize that the examples given by Figs. 3a and 3b are 
for illustrative purposes only. For example, there can be an arbitrary number of product 
types, and an arbitrary number of attributes associated with those product types. Moreover, 
the alphanumeric representation of the attributes and attribute values are exemplary only, and 
can be expressed in any format appropriate to expressing and organizing the information in 
the manner described. For more information regarding the conversion of the database data 
from that in Fig. 3a to that of Fig. 3b, see cross-referenced U.S. Patent Application entitled 
"A Method for Building Digital Catalogs Optimized for Maintenance, Descriptiveness, And 
Fast Search." 

Processing continues at step 54, where if there are extranet buyers established and 
recognized by the application, processing continues to step 56 where searches are performed 
on the transformed version of the catalog database for each set of rules identified by the 
application. Searches are structured based on rules that define what should be viewable to 
each buyer from the entire database 

Referring to Fig. 5b, the details of processing step 56 are illustrated. At processing 
step 560, each rule set is executed as a series of sequential searches on the catalog database. 
With each rule in a rule set defining a search. At processing steps 562 and 564, each time an 
"include" rule is executed, a row is added to a subset table for each SKU returned by the 
search. The row contains a column entry for the SKU and another column entry containing 
the identifier assigned to the rule set being executed. Each time an EXCLUDE rule is 
executed, any SKUs returned by the search having an entry in the subset table are deleted. 
Processing continues at step 56 until the rule sets for all extranet buyers has been performed 
and thus the subset table has been completed. 

Fig. 4 illustrates one possible example of a subset table generated from the catalog 
database data reflected in Fig. 3b by one extranet embodiment of the present invention. The 
first subset might have been returned for a first search associated with a buyer organization 
denoted by subset ID = 001 . The search rules might have been to include all parts where 
product type = desktop computer and vendor = Compaq, or the rule might have been to 
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exclude all parts where the product type = desktop computer and vendor = Dell. The search 
for subset = 002 might have been to include all parts where product type = desktop 
computers, or include all parts where product type = desktop computers and modem speed = 
56k. The search for subset = 003 might have been to include all parts where product type = 
5 desktop computers and all parts where product type = printers. 

Once all extranet rule set searches have been completed, the subset table contains a 
set of SKU entries for each rule set that consists of the subset of the catalog database 
comprising a custom catalog the scope of which is defined by the specific rule set used to 
generate it. Processing then continues at step 58, wherein catalog queries from authorized 
LQ users of any extranet buyer may be initiated through a web browser, which are communicated 
=0 over the Internet to the web server application, which then presents the query along with the 
m buyer's identification to the catalog publishing application. The buyer's identification 
4= corresponds to the rule set that governs which custom catalog subset is appropriate for that 
H buyer. 

The query from the buyer could be for example, to include all items. In this case, the 
y 1 application issues the request to the database server, which first retrieves and returns all 
151 SKUs in the catalog database, corresponding to processing step 580 of Fig. 5c. The database 
server then performs a join to the subset table to determine which of the retrieved SKUs also 
has an entry associated in the subset table for the buyer's identifier. The database server than 
20 returns all SKUs from the catalog database that also are found with an entry in the subset 

table along with the appropriate rule set (or search) ID. This step corresponds to processing 
step 582 of Fig. 5c. In this simple example, the entire custom catalog for that buyer is 
returned. Along with the returned SKUs, the database server also returns all associated 
descriptive information for each of the items identified with the SKUs. The application in 
25 turn presents the information to the web server, which in turn provides the pages of catalog 
data to the user's browser for display on the user's computer. This step is represented by step 
584 of Fig. 5c. 

In one embodiment, upon successful access to the web server application through a 
password or other known technique for restricting such access, the buyer-authorized user is 
30 presented with one or more web pages concerning the catalog. These web pages are designed 
to facilitate the user's browsing of the custom catalog and the formulation of browsing 
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queries based on a user- friendly browsing hierarchy. To be effective, such a user- friendly 
browsing hierarchy must be cognizant of the customized scope of the particular custom 
catalog for a given buyer. Such a browsing hierarchy is disclosed in cross-referenced U.S. 
Patent Application entitled "Display Catalog with Constraint Based Hierarchy and 
5 Propagation Features." 

Referring back to decision step 54, if non-extranet buyers have also been identified, 
processing for those buyers proceeds at processing step 60. At step 60, searches are run on 
the catalog database for all of the rule sets assigned to non-extranet buyers in virtually the 
same manner as at processing step 56. One difference is that separate catalog subset tables 
W are created for each of the rule sets assigned to non-extranet buyers. Processing then 
d} continues at processing step 62, where catalog data, including all descriptive information 
|Cs associated with each item SKU, is extracted from the catalog database for all SKUs in each 
if : catalog subset table. In essence, a complete copy of the catalog subset is created for each rule 
M set assigned to a non-extranet buyer. This must be done because, unlike the extranet buyer, 
T5 the non-extranet buyers are not directly coupled to the catalog database. Finally, at step 64 a 
:!!: copy of the extracted catalog data is then created and formatted for each non-extranet buyer 
U* assigned to the rule set from which the extracted data has been generated, and at step 66 
m formatted copy of the extracted catalog data is then exported to the non-extranet buyer's web 
I" site at step 66. The extracted catalog subset can be provided in an XML format, or it can be 
20 converted to the buyer's format during step 64. Typically, a procurement network has its 
own standard format to which the subset of the catalog data must be converted. The 
procurement network proprietor may specify that the customized subset generated at step 62 
to be formatted in some intermediate format, which the proprietor can then convert to the 
format of the network. 

25 Figs. 6a-6h illustrate screen shots produced by the application on a seller-authorized 

user's web browser by which a rule set is developed for a fictitious extranet buyer or list of 
buyers called Sellco, the process which is initiated by activating the "Create Subset" button 
as shown in Fig. 6a. In this case, Fig 6a illustrates that a catalog subset has already been 
created for Sellco. By selecting Sellco and catalog subsets, the Sellco rule set is displayed in 

30 Fig 6b. The terms "Show" and "Hide" are used interchangeably with the terms "Include" and 
"Exclude" as used hereinabove. To add to the rule set already created, the user selects the 
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"Add Rule" button as shown on Fig. 6b. Fig. 6c shows the first option for creating the rule is 
to select between "Hide" or "Show" to create the next rule. Fig. 6d shows that "Hide" was 
selected, and now a product type is selected from the drop-down list box, from which "CD 
Player" is selected. Fig 6e illustrates that a Vendor attribute can be optionally selected from 
5 the drop down list. Fig. 6f illustrates that upon activating (i.e. clicking on) the "Refine" 

button, additional attributes unique to the product type can also be selected from a drop down 
list. Fig. 6g illustrates that the "Availability" attribute has been chosen, and the attribute 
operator can be selected from a drop down list and a value inserted in the text box to the right 
of the operator. Finally, Fig. 6h illustrates that another buyer can be associated with a set of 
10 rules. 

=11 Those of skill in the art will recognize that regardless of whether the custom catalog 

m subsets are provided to buyers through export to offline web sites or procurement networks, 
%z or directly through on-line extranets, the method and apparatus of the present invention 
M makes it far easier on the seller to publish custom catalogs for its various buyers. The seller 
15 need only create and maintain a common catalog database in one physical location that 
Zl represents the superset all available goods/services offered by the seller. The seller then 
H simply establishes a set of rule based searches, one for each buyer or buyer organization, and 
•j=s then generates the custom subset of the superset by executing the searches and returning a set 
i=b of SKUs for each buyer. If the database is updated, the seller need only run the established 
20 sets of rules to publish updated custom catalogs for each buyer. If the relationship between 
seller and buyer evolves and requires a different scope of products or services to be included 
in that buyer's catalog, only the set of rules needs to be altered, at which point the buyer's 
catalog is simply regenerated using the same database. 

The above embodiments illustrate but do not limit the invention. In particular, the 
25 invention is neither limited by the types of computers used as servers, nor the operating 
systems, web server or database server application software running on such servers. The 
invention is limited neither by the types of user terminals used to connect to the servers, nor 
the type of browser software resident on the terminals. The invention is neither limited by 
the structure of the data as stored in the database, nor is it limited by the nomenclature used in 
30 identifying data types and attributes. The invention does not have to be implemented using 
the Internet, but rather may be implemented over any network, using any type of transmission 
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protocol and display formats. Those of skill in the art will recognize that while a single 
centrally maintained catalog database is illustrated, one could have a number of databases or 
other partitioning of the data from which the custom catalogs could be generated without 
exceeding the intended scope of the invention. 

In addition, while the invention is illustrated in the disclosed embodiments as a 
centrally maintained catalog subset for a seller, those of skill in the art will recognized that it 
may also be used by, for example, a large buyer maintaining a database of desired requisition 
items. A number of suppliers could be authorized to respond to some subset of such requests 
by the buyer, and the invention could be used to constrain the various requests for materials 
or services seen by any particular supplier. 

Finally, many embodiments of the present invention have application to a wide range 
of industries including the following: computer hardware and software manufacturing and 
sales, professional services, financial services, automotive sales and manufacturing, 
telecommunications sales and manufacturing, medical and pharmaceutical sales and 
manufacturing, and construction industries. Other embodiments and variations are within the 
scope of the invention, as defined by the appended claims. 
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